Modern integrated circuit designs have become extremely complex. As a result, various techniques have been developed to verify that circuit designs will operate as desired before they are implemented in an expensive manufacturing process. For example, logic simulation is a tool used for verifying the logical correctness of a hardware design. Designing hardware today involves writing a program in the hardware description language. A simulation may be performed by running that program. If the program (or model) runs correctly, then one can be reasonably assured that the logic of the design is correct at least for the cases tested in the simulation.
Software-based simulation, however, may be too slow for large complex designs such as SoC (System on Chip) designs. Although design reuse, intellectual property, and high-performance tools all can help to shorten SoC design time, they do not diminish the system verification bottleneck, which consumes 60-70% of the design cycle. Hardware emulation provides an effective way to increase verification productivity, speed up time-to-market, and deliver greater confidence in final products. In hardware emulation, a portion of a circuit design or the entire circuit design is emulated with an emulation circuit or “emulator.”
Two categories of emulators have been developed. The first category is programmable logic or FPGA (field programmable gate array)-based. In an FPGA-based architecture, each chip has a network of prewired blocks of look-up tables and coupled flip-flops. A look-up table can be programmed to be a Boolean function, and each of the look-up tables can be programmed to connect or bypass the associated flip-flop(s). Look-up tables with connected flip-flops act as finite-state machines, while look-up tables with bypassed flip-flops operate as combinational logic. The look-up tables can be programmed to mimic any combinational logic of a predetermined number of inputs and outputs. To emulate a circuit design, the circuit design is first compiled and mapped to an array of interconnected FPGA chips. The compiler usually needs to partition the circuit design into pieces (sub-circuits) such that each fits into an FPGA chip. The sub-circuits are then synthesized into the look-up tables (that is, generating the contents in the look-up tables such that the look-up tables together produce the function of the sub-circuits). Subsequently, place and route is performed on the FPGA chips in a way that preserves the connectivity in the original circuit design. The programmable logic chips employed by an emulator may be commercial FPGA chips or custom-designed emulation chips containing programmable logic blocks.
The second category of emulators is processor-based: an array of Boolean processors able to share data with one another is employed to map a circuit design, and Boolean operations are scheduled and performed accordingly. Similar to the FPGA-based, the circuit design needs to be partitioned into sub-circuits first so that the code for each sub-circuit fits the instruction memory of a processor. Whether FPGA-based or processor-based, an emulator performs circuit verification in parallel since the entire circuit design executes simultaneously as it will in a real device. By contrast, a simulator performs circuit verification by executing the hardware description code serially. The different styles of execution can lead to orders of magnitude differences in execution time.
An emulator typically has an interface to a workstation server (workstation). The workstation provides the capability to load the DUV (design under verification, also referred to as DUT—design under test) model, controls the execution over time, and serves as a debugging interface into the DUV model on the emulator. Due to software nature of operations in the workstation, communications between the workstation and the emulator during emulation often require slowing down or even temporarily suspending design clock signals running in the emulator. This is particularly true for emulators used in a simulation acceleration environment or in a hardware/software co-verification environment. In addition to communications with the workstation, other activities such as the need for multiple accesses to a hardware resource may also require slowing down or temporarily suspending design clock signals running in the emulator. For example, the design may need to read/write several locations of a design memory though a limited number of ports before the next associated design clock rising edge. In order to emulate these operations according to the design, the design clock signals may have to be suspended for a number of cycles of the emulator infrastructure clock signal. The rest of this disclosure focuses on using communications with the workstation as an example to illustrate various implementations of the invention. A person of ordinary skill in the art, however, would appreciate that the present invention can be applied to other activities that may need adaptive clock management according to various embodiments of the invention.
In an in-circuit-emulation (ICE) environment, on the other hand, an emulator models a part of a system and connects to real hardware that serves as another part of the system. The real hardware is often referred to as target(s). Even though the emulator can operate at a raw speed up to a few MHz, a target typically has to operate at a slower frequency than in a normal operational mode to match the clock rate of the emulator. For example, PCI's lowest bus frequency is 33 MHz, which is too fast for emulation.
As seen from the above, communications of an emulator with its software environment and with its hardware targets have conflicting clock speed preferences. This may not be problematic as long as targets are static. A target is static if the emulator can temporarily suspend design clock signals. During emulation, temporary suspension of design clock signals can be used when there is a need to compensate for the slow speed of software execution. Emulation resumes normally when the design clock signals are restarted.
A dynamic target, however, requires design clock signals to run continuously above a threshold speed. For example, if a personal computer is connected to the emulator through a PCIe bus as a target, the protocol may run into timeout errors if the clock signal associated with the PCIe bus is stopped for too long or is running at a speed too slow. Typically, a speed-bridging device may be inserted between the emulator and the dynamic target to bridge the speed gap. Even with this device in place, there may still be a threshold speed (although more manageable now) above which the clock signal supplied to the dynamic target by the emulator has to run. It is thus desirable to search for techniques that can adaptively manage clock signals for an emulator to optimize its overall performance.